A split-architecture network design introduces a separation between the control and forwarding components of a network. Among the use cases of such architecture are the access/aggregation domain of carrier-grade networks, mobile backhaul, cloud computing, and multilayer (L3 & L2 & L1, OTN, WDM) support, data centers, all of which are among the main building blocks of a network architecture. Therefore, proper design, management and performance optimization of these networks are of great importance.
Unlike the traditional network architecture, which integrates both the forwarding (data) and the control planes in the same box (network element), a split architecture network decouples these two planes and executes the control plane on servers that might be in different physical locations from the forwarding elements (switches). The use of a split architecture in a network enables the simplification of the switches implementing the forwarding plane and shifts the intelligence of the network into a number of controllers that oversee the switches.
The tight coupling of the forwarding and control planes in a traditional architecture usually results in an overly complicated control plane and complex network management. This is known to create a large burden and high barrier to new protocols and technology developments. Despite the rapid improvement of line speeds, port densities, and performance, the network control plane mechanisms have advanced at a much slower pace than the forwarding plane mechanisms.
In a split architecture network, controllers collect information from switches, and compute and distribute the appropriate forwarding decisions to switches. Controllers and switches use a protocol to communicate and exchange information. An example of such protocol is OpenFlow (see www.openflow.org), which provides an open and standard method for a switch to communicate with a controller, and it has drawn significant interest from both academics and industry. FIG. 1 is a diagram showing an overview of the OpenFlow interface between a switch and a controller. The forwarding table in an OpenFlow switch is populated with entries consisting of: a rule defining matches for fields in packet headers; an action associated to the flow match; and a collection of statistics on the flow.
When an incoming packet matches a particular rule, the associated actions are performed on the packet. A rule contains key fields from several headers in the protocol stack, for example Ethernet MAC addresses, IP address, IP protocol, TCP/UDP port numbers as well as the incoming port number. To define a flow, all the available matching fields may be used. But it is also possible to restrict the matching rule to a subset of the available fields by using wildcards for the unwanted fields.
The de-coupled control platform of the split architecture eases the task of modifying the network control logic and provides a programmatic interface upon which developers can build a wide variety of new protocols and management applications. In this model, the data and control planes can evolve and scale independently, while the cost of the data plane elements is reduced.